The professor entered the classroom. She set her tablet down on a desk and took a seat in front of the classroom. There were twenty chairs there for the audience; perhaps half of them were filled. Andrea was Cambridge's Professor of Data Archeology. Though many students viewed data archeology as a field too old to still hold value, a few devout every year would still attend her classes.
It was the second class of the semester. The first class had been given over to introductions and some context regarding the subject. Some of the more renowned data archeologists of recent history were mentioned and their accomplishments described. Andrea located her notes on her tablet and began to speak.
"Welcome again, all, to our second class of the Introduction to Data Archeology course."
"Last week we retired after discussing some remarkable data archeologists, and this gives you some background into the profession. Today we will be laying the foundation for further discussion by defining some important terms."
"In the field of data archeology we say that there are two kinds of software. Applications, and tools. Though, realistically, it is not a true dichotomy. It's not a spectrum, either, with applications at one end and tools at the other. Like a scatter graph with two axes, usefulness as an application and usefulness as a tool, with the notable property that the overwhelming majority of points will fall close to the axes on this graph. That is, they will be recognizable as serving either one purpose or the other. And in some cases you will find points quite near the origin, representing software that is useful as neither." Andrea expressed the final point with humor and the students laughed quietly.
"These terms can be somewhat confusing as it's not immediately obvious what would be the difference between an application and a tool. The terms come from the history of computing and software terms; in the early 21st century almost all software was referred to as applications. It was only some decades later before the word "tool" came into common use in describing software, and it was meant to distinguish a category of software from those that were called applications. It wasn't that tools were an entirely new category of software so much as they had previously played a less visibly major role than applications."
Andrea connected the classroom's projector to her tablet and drew a simple diagram. "In summary, an application solves a problem existing in the external, physical world and a tool solves an abstract, conceptual problem in expressing the solution to an external one. And though this has not remained strictly true across all of the software history we've been looking at, it is reasonably accurate to say that, through most of software history, tools begat applications begat real-world impacts. It's similar to the difference between applied mathematics, which expresses and measures our physical reality, and pure mathematics, which expresses a conceptual and ideal reality."
"This classification of application versus tool is not only applicable to old software; you could apply it to modern software, too. The things is that you'd find yourself categorizing very nearly all modern software as tools." Andrea wrote some examples of well-known software underneath the categories "application" and "tool". Mostly the students did not recognize the names provided under the "application" category.
"It was in the mid-twenty-first century that the first practically-useful artificially intelligent algorithms were described, and over the next seventy or so years they evolved and were built upon and matured until they became the sorts of patterns that empower the software we use today. Before ailgos, as they were sometimes called, people needed to create and use both tools and applications. Following their maturity, applications have become, in a sense, obsolete."
Andrea showed examples of ailgos on the projector. The list included some obvious ones that anyone with a background in software would be familiar with, such as arithmetic engines, physics solvers, and economics modelers, and some that were new to many of the students, such as provability analyzers, probability manipulators, and entity descriptors. The text on the projector explained how arithmetic engines derived any required mathematics from first principles and was capable of applying them to arithmetic problems, how physics solvers invented descriptions of physical behaviors by analyzing real-world observations and finding patterns, how economics modelers applied computations that many would describe as intuitive as a way to circumvent the demand of a full simulation, how provability analyzers were capable of finding whether a statement could possibly be proven and how and with what confidence, how probability manipulators could advise a user on what actions to take to minimize or maximize the probability of some outcome, how entity descriptors had a vast encyclopedic knowledge that could be employed in identifying entities and discovering their likely properties.
Andrea said, "Another way to understand the difference between applications and tools is to observe that applications were software serving narrow purposes, solving some very specific and contemporary set of problems. Encoding an image in a way that some particular device could understand. Or enabling and tracking financial transactions to and from a particular organization, specialized to account for that organization's resources and limitations and infrastructure. These kinds of problems often no longer existed in a meaningful form a decade later, or a year later, or even a month later. Tools solve broader sets of problems, ones that often never cease to exist, such that we could still apply tools written years ago to the software problems we're having today, even though those problems could never have been predicted when the tools were written."
"In the early history of software, applications were almost always assigned a much greater value and importance relative to tools because they yielded much greater short-term gains than tools. For many years, many more applications were made than tools. But then, especially with the maturity of ailgos which could be applied not so much to some broad set of problems as to an entire category of problems — a bit like the difference between software that enumerates all the integers we know of, and software that understands how integers are defined and from that understanding is able to do many more things than merely enumerate those items meeting the definition - this began to change."
"I mentioned before that the set of problems an application was designed to solve could often become irrelevant, and thereby the software stripped of all practical usefulness, within years or even months after its creation." Andrea showed a graphic on the projector which graphed application lifespan as a function of time. "What's very important to understand, the reason why modern software is almost exclusively tools and almost never applications, is how that typical term of usefulness for any given application decreased as time progressed. In 1980, an application might still be useful after ten years. In 2010, most applications were no longer useful after one year. At first this produced an environment where applications were continuously maintained and updated in order to remain relevant to contemporary problem sets; otherwise the applications would cease to be profitable to those who had invested resources in them. The pressure eventually became so severe that it was almost impossible to develop an application quickly enough that the problem set it was intended to solve would still meaningfully exist when that application was complete and functional."
"Today, the problems we apply software are extremely temporary, but only in the sense that if we fail to solve them quickly they will spawn greater problems, and if we succeed in solving them quickly they will no longer matter tomorrow. Obviously, developing applications to address these extremely short-lived problems, one-by-one, as they appeared, would be grossly impractical. This is why ailgos are so important. Only with tools — software that is almost universally empowered by ailgos — are able to devise general solutions to real problem sets, and to change and adapt those solutions according to the problem set's continued changes."
Andrea detached her tablet from the projector. She concluded: "Now the important question is, what will tomorrow's data archeologists say about the software we have today? I urge you to come to class next week with ideas and ready for a discussion."